home *** CD-ROM | disk | FTP | other *** search
/ Internet Tools (InfoMagic) / Internet Tools.iso / dos_win / winsock / maillist / 94-05.Z / 94-05 / 000342_towfiq@suneast.east.sun.com_Sat May 21 09:52:00 1994.msg < prev    next >
Internet Message Format  |  1994-05-31  |  28KB
  1. Received: from Sun.COM by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  2.           id AA04942; Tue, 24 May 1994 19:25:45 -0400
  3. Received: from East.Sun.COM ([129.151.1.15]) by Sun.COM (sun-barr.Sun.COM)
  4.     id AA11973; Tue, 24 May 94 16:19:04 PDT
  5. Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1)
  6.     id AA22588; Tue, 24 May 94 14:53:25 EDT
  7. Received: from oaktree.East.Sun.COM by suneast.East.Sun.COM (4.1/SMI-4.1)
  8.     id AA17991; Tue, 24 May 94 14:53:13 EDT
  9. Received: by oaktree.East.Sun.COM (5.0/SMI-SVR4)
  10.     id AA13882; Tue, 24 May 1994 14:52:43 +0500
  11. Message-Id: <9405241852.AA13882@oaktree.East.Sun.COM>
  12. Return-Path: <davidtr@microsoft.com>
  13. From: davidtr@microsoft.com
  14. To: winsock@sunsite.unc.edu
  15. Subject: *** Next Rev Of Winsock2 Framework Doc ***
  16. Reply-To: martinh@jsbus.com (Martin Hall)
  17. Date: Sat, 21 May 94 16:52:00 PDT
  18. X-Mailer: Microsoft Mail V3.0
  19. Content-Length: 22646
  20.  
  21. Below is the latest revision of the Windows Sockets 2.0 framework document. 
  22. It includes changes based on the Interop meeting and other feedback we've 
  23. received.
  24.  
  25. Please note that the deadline for volunteering as a group administrator is 
  26. this Tuesday, May 24.  As outlined in previous mail, please contact 
  27. martinh@jsbus.com if you are interested.
  28.  
  29. Martin, Mark, and Dave
  30.  
  31.  -----------------------------------------------
  32. Windows Sockets Version 2 - Operating Framework
  33.  -----------------------------------------------
  34.  
  35. Date:             May 20, 1994
  36. Project Status:   Phase 1
  37. Authors:          Martin Hall, Dave Treadwell, Mark Towfiq
  38.  
  39. This document is organized as follows
  40.  
  41. 1. Objectives (Why are we doing this?)
  42. 2. Mission Statement
  43. 3. Overview  (What's it all about?)
  44. 4. Specification Paramaters & Requirements
  45.           4.1 General Referential Paramaters
  46.           4.2 Technical Requirements
  47. 5. Organizational Framework
  48.         5.1 Moderators
  49.         5.2 Review Boards
  50.                 5.2.1 Review Board Administrators
  51.                 5.2.2 Application Review Board
  52.                 5.2.3 Transport Review Board
  53.         5.3 Functionality Groups
  54.                 5.3.1  Functionality Group Administrators
  55.                 5.3.2  Generic API Extensions & Additions
  56.                 5.3.3  Specification Clarifications
  57.                 5.3.4  Name Resolution
  58.                 5.3.5  Operating Framework
  59.                 5.3.6  TCP/IP
  60.                 5.3.7  IPX/SPX
  61.                 5.3.8  Appletalk
  62.                 5.3.9  Connection-Oriented Media
  63.                 5.3.10 OSI
  64.                 5.3.11 Wireless
  65. 6. Timeframes (Project Phases)
  66. 7. Discussion Forums
  67.  
  68.  ------------
  69. Introduction
  70.  ------------
  71. This is a rolling document that defines the framework for the
  72. creation of the Windows Sockets Version 2 specification. As the
  73. document is changed, the date at the head will change. Please note
  74. the status indicates the phase we are in as laid out in the
  75. Timeframes section in this document.
  76.  
  77.  --------------------------------------
  78. 1. Objectives (Why are we doing this?)
  79.  --------------------------------------
  80. Windows Sockets has succeeded to date because
  81. 1. It has met the needs of application developers ("I'm tired of all these
  82. different API's!")
  83. 2. It has led to easier decisions for end users ("I want a Windows Sockets
  84. app, I want a Windows Sockets compliant stack and I want them now!")
  85. 3. It's been fun and pursued in a great spirit of cooperation
  86.  
  87. The burgeoning implementation of LAN environments, the rise and rise of
  88. TCP/IP, the widespread acceptance of Windows Sockets in the application
  89. developer community and amongst application users have all helped make
  90. Windows Sockets something of a de facto standard in a very short period of
  91. time. It is therefore natural to consider amending and extending Windows
  92. Sockets to make it the de facto transport API for all data communication
  93. irrespective of protocol.
  94.  
  95.  --------------------
  96. 2. Mission Statement
  97.  --------------------
  98. The goal of Windows Sockets 2 is to make it a ubiquitous transport level
  99. API available in all Windows operating systems and capable of supporting
  100. multiple data transports simultaneously. It will allow flexible addition
  101. of transport functionality while providing a consistent API base for
  102. straightforward application development. Windows Sockets 2 will standardize
  103. the API such that similar functionality in different transports will be
  104. accessible via common mechanisms. It will also provide mechanisms for
  105. applications to access essential characteristics that are specific to
  106. particular classes of transports.
  107. All this serves to help reach the ultimate goal of Windows Sockets: to
  108. provide a truly transport-independent API that allows developers to create
  109. transport-independent and transport-efficient applications and allows users
  110. to select applications based on functional merit rather than the transports
  111. they support.
  112.  
  113.  ----------------------------------
  114. 3. Overview (What's it all about?)
  115.  ----------------------------------
  116. The Windows Sockets Version 2 specification will extend Windows Sockets
  117. Version 1.1 in 3 key areas
  118.  
  119. 1. API Extensions
  120. Over 2 years experience of Windows Sockets has led to various suggestions
  121. for improvements to the existing specification. There are a number of
  122. proposals for API additions and extensions which make it even easier for
  123. application developers to utilize Windows Sockets implementations.
  124. Some of these extensions are likely to be generically applicable, some will
  125. be transport specific.
  126.  
  127. 2. Multiple Network Transport Capabilities
  128. The success of version 1.1 of Windows Sockets has led to a clamor for
  129. support of network transports other than TCP/IP. Requests have been
  130. made to design support for IPX/SPX, Appletalk, OSI and DECnet specifically.
  131. In response to demand for a standard data transfer API for emerging
  132. technology such as ATM and telephony-based transports, there will also be
  133. consideration of how best to enable this in a Windows Sockets framework.
  134. The design groups in Windows Sockets 2 will also seek to create a generic
  135. architectural framework that will host any network transport.
  136.  
  137. 3. Operating System Considerations & Architectural Issues
  138. The Microsoft Windows Operating System platforms will soon be extended
  139. beyond Windows 3.1 and Windows NT for which Windows Sockets 1.1 was
  140. designed. Windows Sockets Version 2 will take into account not just
  141. these platforms but forthcoming versions of both Windows NT and
  142. Chicago. An important goal of Windows Sockets 2 is thus ensuring that
  143. Windows Sockets applications can be well-integrated within these
  144. operating systems.
  145.  
  146.  ---------------------------
  147. 4. Specification Parameters
  148.  ---------------------------
  149.  
  150. 4.1 General Referential Parameters
  151.  ----------------------------------
  152. The following list of parameters is designed to help us all clearly
  153. understand the parameters around what we are trying to achieve. Windows
  154. Sockets 1.1 succeeded in part because we had a clear set of parameters
  155. against which to measure and judge the specific applicability of any
  156. particular piece of functionality. Everything we consider in every
  157. Functionality Group should be prescribed by the following parameters.
  158. Please note that these parameters are numbered for easy reference.
  159.  
  160. 1.  Don't introduce API changes that preclude a vendor from
  161.     simultaneously supporting 1.1 and future versions
  162.  
  163. 2.  Enable Windows Sockets 1.1 apps to become Windows Sockets 2 apps with
  164.     minimal code changes
  165.  
  166. 3.  The only changes to the Windows Sockets 1.1 API set will be
  167.     specification clarifications
  168.  
  169. 4.  New functionality will be added in such a way that it's clearly
  170.     distinguishable from the Windows Sockets 1.1 API set
  171.  
  172. 5.  Wherever possible, new API's should be supersets of old API's
  173.  
  174. 6.  Follow existing precedents.
  175.     For example, we will continue to use BSD 4.3 Sockets as a guiding
  176.     model where possible. Where recognized work has already been
  177.     done in a particular area we should make use of it.
  178.  
  179. 7.  Windows Sockets 2 specification to be complete and final by April 30, 
  180. 1995
  181.  
  182. 8.  Facilitate high performance implementations.
  183.  
  184. 9.  New functionality to be driven by application and end user
  185.     requirements.
  186.  
  187. 10. Don't try to do everything; prioritize proposed changes & additions
  188.     and focus on highest priority items.
  189.  
  190. 11. Where possible, implement functionality generically.
  191.     We want to ensure that we solve similar problems worked on
  192.     by different Functionality Groups in a common and consistent way.
  193.  
  194. 12. Enable transport-independent applications. It should be possible
  195.     to write an application that works over any transport without
  196.     knowing the details of any one transport.
  197.  
  198. 13. Enable transport-efficient applications. It should be possible
  199.     to write a transport-specific application that takes advantage
  200.     of special features of a particular transport.
  201.  
  202. 14. Mandatory functionality for any particular transport must be consistent
  203.     and logical.
  204.  
  205. 15. Ensure that proposed functionality changes & additions mesh with
  206.     each other and with Windows API's and operating system services.
  207.  
  208. 16. Windows Sockets is not SNMP.
  209.  
  210. 17. Optional functionality should be generally useful and the exception
  211.     rather than the rule.
  212.  
  213. 4.2 Technical Requirements
  214.  --------------------------
  215. Each Functionality Group will have a clear set of requirements which
  216. define the problems it is trying to address. The initial work of each
  217. Functionality Group will be to define these requirements in the context
  218. of the Referential Parameters set out above.
  219.  
  220.  ---------------------------
  221. 5. Organizational Framework
  222.  ---------------------------
  223. The success of Windows Sockets 1.1, the complexity and breadth of issues
  224. under discussion for Windows Sockets version 2 and the number of people
  225. now involved in the various Windows Sockets forums means we need a clearer
  226. operational structure for progress this time around.
  227.  
  228. In order to allow everyone to contribute to areas which they care
  229. about we have designed the following operational structure to
  230. facilitate discussion and to enable maximum progress. The most
  231. important groups are the Review Boards and Functionality Groups.
  232. Together, these groups will be responsible for discussing, agreeing and
  233. designing new functionality.
  234.  
  235.  --------------
  236. 5.1 Moderators
  237.  --------------
  238. Martin Hall, Dave Treadwell and Mark Towfiq will act largely as
  239. coordinators of the Windows Sockets 2 effort. They will be responsible
  240. for:
  241.  
  242. * Coordinating the various groups to ensure that the process
  243.   moves in the right direction.
  244.  
  245. * Facilitating information flow between the groups so that new
  246.   features are implemented consistently.
  247.  
  248. * Producing the consolidated header file for Windows Sockets 2.
  249.  
  250. * Working with the Review Boards to help consolidate specification
  251.   sections produced by the Functionality Groups.
  252.  
  253. * Handling public relations for Windows Sockets 2.
  254.  
  255. * Working with the Review Boards to address discrepancies between the
  256.   work produced by each Functionality Group.
  257.  
  258.  -----------------
  259. 5.2 Review Boards
  260.  -----------------
  261. The reason for establishing Review Boards is to enable the ongoing
  262. pragmatic goals of Windows Sockets to be realized. In the world of
  263. Windows Sockets, pragmatism is defined by
  264.  
  265. 1. The applicability of Windows Sockets functionality to application
  266.    developers.
  267. 2. The ease with which functionality can be implemented by
  268.    Windows Sockets providers (typically, but not necessarily,
  269.    network transport vendors)
  270.  
  271. To this end, there will be 2 Review Boards. Each board will
  272. review submissions from each Functionality Group in the light of the
  273. pragmatic goals of Windows Sockets. Each Review Board will have an
  274. administrator with responsibilities as outlined above.
  275.  
  276. 5.2.1 Review Board Administrators
  277.  ---------------------------------
  278. The responsibilities of the administrator of each Review Board are to
  279. ensure:
  280.  
  281. * Refinement of requirements initially proposed by Functionality Groups
  282.  
  283. * Progress according to the key milestones
  284.  
  285. * Discussions framed by general referential paramaters
  286.  
  287. * Design decisions meet the referential paramaters and the Windows Sockets 2
  288.   requirements
  289.  
  290. * Consistency of proposals from Functionality Groups
  291.  
  292. * Arrangement of meetings on an as needs basis
  293.  
  294. * Regular communication with moderators
  295.  
  296. 5.2.2 Application Review Board
  297.  -------------------------------
  298. Charter: The Application Review Board will review submissions from
  299.          each Functionality Group. It will focus on the submission's
  300.          applicability to and ease of use by application developers as
  301.          well as confirming that functionality required by applications
  302.          is supported.
  303.  
  304. Membership: A maximum of one representative from each company will
  305.             contribute to this group.
  306.  
  307. 5.2.3 Transport Review Board
  308.  -----------------------------
  309. Charter: The Transport Review Board will review submissions from
  310.          each Functionality Group. It will focus on the ease of
  311.          implementation of a piece of functionality.
  312.  
  313. Membership: A maximum of one representative from each company will
  314.             contribute to this group.
  315.  
  316. 5.3 Functionality Groups
  317.  ------------------------
  318. The reason for establishing Functionality Groups is to break up
  319. the large body of issues that require discussion for Windows Sockets 2 into
  320. manageable chunks. The following groups will also allow people to focus
  321. on areas of particular interest and ignore ones they don't care about.
  322.  
  323. Each Functionality Group will have an administrator responsible for
  324. coordinating the group's discussion and ensuring that the general
  325. parameters and timeframes for Windows Sockets 2 are met.
  326.  
  327. Please note that at this point the proposals listed below are just that.
  328. Each group will define the actual requirements which may lead to the
  329. exclusion of some proposals listed below and/or the inclusion of others
  330. not listed. Phases 1 and 2 as outlined below will see the production
  331. of a Requirements Document for each Functionality Group.
  332.  
  333. 5.3.1 Functionality Group Administrators
  334.  ----------------------------------------
  335. The responsibilities of the administrator of each Functionality
  336. Group are to ensure:
  337.  
  338. * Progress according to the key milestones
  339.  
  340. * Regular communication with other functionality groups
  341.  
  342. * Discussions framed by general referential paramaters
  343.  
  344. * Design decisions meet the referential paramaters and the group's
  345.   requirements
  346.  
  347. * Arrangement of meetings on an as needs basis
  348.  
  349. * Regular communication with moderators
  350.  
  351. * Ultimate responsibility for producing actual specification sections
  352.   for the group
  353.  
  354. * Moderation of the group's mailing list: keep high signal-to-noise ratio
  355.  
  356. 5.3.2 Generic API Extensions & Additions
  357.  -----------------------------------------
  358. Charter: To design and specify general extensions to the Windows Sockets
  359.          API. Features and changes should be applicable to multiple
  360.          transport protocols.
  361.  
  362. Proposals:
  363.     Improved support for other languages: C++, Basic, Pascal
  364.     True asynchronous send() and recv() mechanisms
  365.     Ability to share sockets between tasks/processes
  366.     "Deferred accept()"--don't establish connection immediately
  367.     SO_SNDTIMEO and SO_RCVTIMEO socket options
  368.     4-byte per-socket context value stored by Windows Sockets DLL
  369.     Standard routine to map Windows Sockets error codes to strings
  370.     Application yielding, blocking hooks
  371.     Socket Groups
  372.     Support for message-oriented (partial) receives
  373.     Per-socket query of max message length
  374.     Support for connect and disconnect data
  375.     Transaction-oriented transport support
  376.     Mechanism for querying optional functionality
  377.     Scatter write, gather read
  378.     sethostname()
  379.     Mechanism to retrieve network statistics
  380.  
  381. 5.3.3 Specification Clarifications
  382.  -----------------------------------
  383. Charter: Resolve ambiguities in the Windows Sockets specification to
  384.          ensure that all Windows Sockets implementations have a
  385.          consistent interpretation of the interface.
  386.  
  387. Proposals:
  388.     WSAAsyncSelect() issues
  389.     Multiple versions supported by a single Windows Sockets DLL
  390.     Unconnecting datagram sockets
  391.     FD_CLR performance improvements
  392.     s_port in servent struct is int
  393.     Stack space requirements on winsock DLL
  394.     NULL array pointers in hostent struct
  395.     Structure packing of servent, protoent
  396.     winsock.h: all ports, ip addrs in NETWORK order
  397.     closesocket() on nonblocking sockets
  398.     Samples for every API
  399.     FD_READ contains error--> no need for recv()
  400.  
  401. 5.3.4 Name Resolution
  402.  ----------------------
  403. Charter: Design and specify a name-service independent interface which
  404.          allows Windows Sockets applicationt to resolve huiman-readable
  405.          host or service names into Windows Sockets transport addresses
  406.          (SOCKADDRs).
  407.  
  408. Proposals:
  409.     Support for other name service providers
  410.     Host/Service enumeration
  411.     Internationalizable (unicode) name resolution routines
  412.     Dynamic service registration
  413.     Directory Service support
  414.     Define standard location for database files
  415.  
  416. 5.3.5 Operating Framework
  417.  --------------------------
  418. Charter: Ensure that Windows Sockets DLLs and transport protocols can
  419.          coexist in the various operating systems which support Windows
  420.          Sockets.
  421.  
  422. Proposals:
  423.     Operating System versions--Win 3.1, WFW, NT, Chicago
  424.     Configuration
  425.     Architecture
  426.     Multiple Transport Procotol Stacks on a single host via a single DLL
  427.     Multiple Windows Sockets DLLs on a single host
  428.     Clearinghouse for address familys, protoocls, socket types
  429.     Mechanism for determining version of winsock DLL
  430.  
  431. 5.3.6 TCP/IP
  432.  -------------
  433. Charter: Provide TCP/IP-specific extensions to the Windows Sockets API.
  434.  
  435. Proposals:
  436.     ICMP, Raw Sockets, Ping
  437.     RFC 793 & 1122 OOB Data support
  438.     Get/Set/Delete ARP entries
  439.     gethostid()
  440.     SIOCGIFADDR, SIOCGARP, SIOCGHIWAT, SIOCGIFNETMA
  441.     Mechanism to set TTL in IP header
  442.     rresvport()
  443.     IP multicast support (IGMP)
  444.     IPng support
  445.     UDP datagram send size != receive size
  446.     Standardize OOB handling
  447.     Option to disable UDP checksum
  448.  
  449. 5.3.7 IPX/SPX
  450.  --------------
  451. Charter: Provide IPX/SPX-specific extensions to the Windows Sockets API.
  452.  
  453. Proposals:
  454.     No specific ones as yet
  455.  
  456. 5.3.8 AppleTalk
  457.  ----------------
  458. Charter: Provide AppleTalk-specific extensions to the Windows Sockets API.
  459.  
  460. Proposals:
  461.     No specific ones as yet
  462.  
  463. 5.3.9 Connection-Oriented Media (formerly Telephony)
  464.  ----------------
  465. Charter: Extend Windows Sockets to handle connection-oriented
  466.          physical media including ATM, ISDN, etc.
  467.  
  468. Proposals:
  469.     Lots of interest
  470.  
  471. 5.3.10 OSI
  472.  ----------------
  473. Charter: Provide OSI-specific extensions to the Windows Sockets API.
  474.  
  475. Proposals:
  476.     No specific ones as yet
  477.  
  478. 5.3.11 Wireless
  479.  ----------------
  480. Charter: Provide Wireless-specific extensions to the Windows Sockets API.
  481.  
  482. Proposals:
  483.     No specific ones as yet
  484.  
  485.  ------------------------------
  486. 6. Timeframes (Project Phases)
  487.  ------------------------------
  488. We have identified the following timeframes for Windows Sockets
  489. Version 2. Please note that the overall project is broken into
  490. phases so we can easily identify where we are.
  491.  
  492. PHASE 1 - Create First Functionality Group Requirements Drafts
  493.  --------------------------------------------------------------
  494. Functionality Groups create initial Requirement Drafts.
  495. Functionality Group Administrators submit this draft to
  496. the mailing list of each Review Board by Completion Date.
  497.  
  498. Completion Date:        June 6 1994
  499.  
  500. PHASE 2 - Create Final Functionality Group Requirements Drafts
  501.  --------------------------------------------------------------
  502. Review Boards consider the Requirement Drafts.
  503. Functionality Groups refine the Requirement Drafts based on
  504. input from Review Boards.
  505. Functionality Group Administrators submit the final draft to
  506. the mailing list of each Review Board by Completion Date.
  507.  
  508. Completion Date:        Jun 30 1994
  509.  
  510. PHASE 3 - Create first draft Functionality Group specifications
  511.  ---------------------------------------------------------------
  512. Functionality Groups work on solutions in the context of
  513. the Requirements Document for their group.
  514. Functionality Group Administrators submit their Functionality Group's first
  515. draft specification to the mailing list of each Review Board by Completion
  516. Date.
  517.  
  518. Completion Date:        Aug 31 1994
  519.  
  520. PHASE 4 - Create intermediate draft Functionality Group specifications
  521.  ----------------------------------------------------------------------
  522. Review Boards consider the first draft specifications.
  523. Functionality Groups refine the first draft specifications based on
  524. input from Review Boards.
  525. Functionality Group Administrators submit the intermediate draft
  526. specifications tothe mailing list of each Review Board by Completion Date.
  527.  
  528. Completion Date:        Nov 30 1994
  529.  
  530. PHASE 5 - Preliminary Interoperability Testing
  531.  ----------------------------------------------
  532. It is expected that software vendors will be working on Windows Sockets 2
  533. implementations as the specification evolves. This phase will include
  534. the first interoperability testing for Windows Sockets Version 2.
  535.  
  536. Date:                   Jan 1995
  537.  
  538. PHASE 6 - Create final draft Functionality Groups specifications
  539.  ----------------------------------------------------------------
  540. Review Boards consider the intermediate draft specifications & results
  541. of interoperability testing.
  542. Functionality Groups refine draft specs based on Review Board input and
  543. interoperability testing.
  544. Functionality Group Administrators submit the final draft specifications to
  545. the mailing list of each Review Board by Completion Date.
  546.  
  547. Completion Date:        Feb 28 1995
  548.  
  549. PHASE 7 - Interoperability Testing
  550.  ----------------------------------
  551. This phase will include further interoperability testing for
  552. Windows Sockets Version 2.
  553.  
  554. Date:                   Mar 1995
  555.  
  556. PHASE 8 - Complete Windows Sockets 2 specification
  557.  ------------------------------------------
  558. Review Boards consolidate and refine specification.
  559. Windows Sockets 2 specification completed and published by;
  560. completion date.
  561.  
  562. Completion Date:        Apr 30 1995
  563.  
  564.  ---------------------
  565. 7. Discussion Forums
  566.  ---------------------
  567. Email & Newsgroup details
  568.  
  569. With the recent reorganization of the Windows newsgroups, we see a need
  570. to:
  571.  
  572. 1. Create new mailing lists for Windows Sockets 2
  573. 2. Shift the mailing list gated to alt.winsock
  574. 3. Re-think winsock-hackers and winsock-users.
  575.  
  576. Here are the new networking-related newsgroups
  577.  
  578. comp.os.ms-windows.networking.tcp-ip     Windows and TCP/IP etworking
  579. comp.os.ms-windows.networking.windows    Windows' built-in networking
  580. comp.os.ms-windows.networking.misc       Windows and other networks
  581. comp.os.ms-windows.programmer.networks   Network programming
  582.  
  583. For the current mailing lists we propose to
  584. 1. Gate the present winsock mailing list to
  585. comp.os.ms-windows.networking.tcp-ip
  586.  (since, although winsock is not only for TCP/IP, 95% of the traffic on the
  587. mailing list is about TCP/IP).
  588. 2. Gate winsock-hackers to comp.os.ms-windows.programmer.networks.
  589. 3. Drop winsock-users because of minimal usage.
  590.  
  591. For Windows Sockets Version 2 discussion we propose to
  592. 1. Create a new mailing list for discussion of general issues related
  593. to Windows Sockets version 2.
  594. 2. Create separate mailing lists for individual Review Boards and
  595. Functionality Groups.
  596.  
  597. None of these will be gated to a newsgroup, to facilitate focussed
  598. discussion.
  599. -------------------------------------------------------------------------
  600. Martin Hall                         108 Whispering Pines Drive, Suite 115
  601. JSB Corporation                     Scotts Valley, California 95066
  602. martinh@jsbus.com                   Tel: 408-438-8300   Fax: 408-438-8360
  603. From news@bigblue.oit.unc.edu Sun May 25 00:23:18 1994
  604. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  605.           id AA10965; Tue, 24 May 1994 19:55:26 -0400
  606. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  607.           id AA24327; Tue, 24 May 1994 19:40:14 -0400
  608. Received: from GATEWAY by bigblue with netnews
  609.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  610. To: winsock@sunsite.unc.edu
  611. Date: 25 May 1994 00:23:18 GMT
  612. From: jmorphet@asys.com (John P. Morphet)
  613. Message-Id: <2ru5pm$arn@rainbow.sosi.com>
  614. Organization: Advanced Systems
  615. Sender: ses
  616. Subject: Time log program?
  617.  
  618. Sorry if this is the wrong newsgroup, but does anyone know
  619. of a shareware program that keeps track of time logged into a
  620. SLIP server. It wouldn't have to specifically for that purpose. 
  621. If it was designed to work in the background, but could be enabled
  622. from the command line, e.g., "log on" or "log off". If it 
  623. worked like this then it could be entered as a command in the
  624. SLIP login and logoff script.
  625.  
  626.  ___________________________________________________________
  627.                                                            
  628.    John P. Morphet                         jmorphet@asys.com   
  629.    Advanced Systems                     voice (719) 579-9014               
  630.    Colorado Springs, CO., USA           fax   (719) 579-9017                
  631.  ___________________________________________________________
  632. From news@bigblue.oit.unc.edu Wed May 25 00:31:29 1994
  633. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  634.           id AA10981; Tue, 24 May 1994 19:55:29 -0400
  635. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  636.           id AA19518; Tue, 24 May 1994 19:44:30 -0400
  637. Received: from GATEWAY by bigblue with netnews
  638.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  639. To: winsock@sunsite.unc.edu
  640. Date: Wed, 25 May 1994 00:31:29 GMT
  641. From: jones@cbdb1.nimh.nih.gov (Doug Jones)
  642. Message-Id: <jones.47.008244EA@cbdb1.nimh.nih.gov>
  643. Organization: CBDB/NIMH/NIH
  644. Sender: ses
  645. References: <calanan.20.00AE683B@fstrf.org>
  646. Subject: Re: WFWG 3.11, Winsock, and NDIS problems!
  647.  
  648. In article <calanan.20.00AE683B@fstrf.org> calanan@fstrf.org (Michael C. Calanan) writes:
  649. >From: calanan@fstrf.org (Michael C. Calanan)
  650. >Subject: WFWG 3.11, Winsock, and NDIS problems!
  651. >Date: Tue, 24 May 1994 11:47:21 GMT
  652.  
  653. >Has anyone else installed Trumpet Winsock (1.0 A) over Windows
  654. >for Workgroups 3.11 running NetBEUI(NDIS) as the network layer?
  655. >I have the machine running Workgroups successfully now, but 
  656. >when I try to load winpkt.com, I get an error that the packet 
  657. >driver can not be found.
  658.  
  659. Yes, it can be done - the trick is that the NDIS-packet driver shim
  660. (dis_pkt.dos) must be loaded by Windows, via instructions in
  661. system.ini instead of config.sys. To be specific the section of your
  662. system.ini will look something like:
  663. ...
  664.      [network drivers]
  665.      netcard=elnkii.dos
  666.      transport=*netbeui,ndishlp.sys,C:\COMM\DIS_PKT9.DOS
  667.      devdir=c:\windows
  668.      LoadRMDrivers=YES
  669. ...
  670. where the changes are in CAPS. Also, I'm pretty certain that in
  671. protocol.ini you should have
  672. ...
  673.      [pktdrv]
  674.      DriverName=PKTDRV$
  675.      bindings=ms$elnkii
  676.      intvec=0x66
  677. ...
  678. i.e. the DriverName should be the internal name stored inside the
  679. driver itself, pktdrv$, not the arbitrary filename, dis_pkt9.dos.
  680. Finally, it probably doesn't matter, but I'd move the winpkt.com
  681. line to run immediately after net start in autoexec.bat:
  682. ...
  683.     LH c:\windows\net start
  684.     LH C:\WINSOCK\WINPKT.COM 0x66
  685. ...
  686. The rest seems to be fine to me.
  687. As an aside, yeah I ended up with an IPX that I had to hand remove,
  688. don't know why they did that - sure slowwed everything down!! Also,
  689. Trumpet Winsock is _really_ excellent, and I liked it a lot, but I have
  690. since switched to the _free_ MS TCP/IP-32 (Daytona beta) - its a
  691. 32-bit protected mode winsock that installs as an [Add Protocol...]
  692. under the Network Setup icon. And finally... I have an oemsetup.inf
  693. and winpkt.bat that I'll e-mail to you directly that allow you to do an
  694. [Add Protocol...] to install Trumpet Winsock, and avoid the above editting
  695. altogether.
  696. Good Luck,
  697. Doug
  698. jones@cbdb1.nimh.nih.gov
  699.  
  700.